The rts package uses GCC's __atomic built-in functions on 64-bit values. This
is not supported on some 32bit platforms (e.g., mipsel) resulting in the
following compilation error:
rts/dist/build/libHSrts_thr-ghc8.10.7.so: error: undefined reference to '__atomic_load_8'
rts/dist/build/libHSrts_thr-ghc8.10.7.so: error: undefined reference to '__atomic_store_8'
rts/dist/build/libHSrts_thr-ghc8.10.7.so: error: undefined reference to '__atomic_fetch_add_8'
Fix this by linking against libatomic.
Author: Ilias Tsitsimpis <iliastsi@debian.org>
Bug: https://gitlab.haskell.org/ghc/ghc/-/issues/20549
Forwarded: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6820
GHC 8.10 fails to build on armel with the following error:
LLVM ERROR: unable to allocate function argument #8
PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace.
Stack dump:
0. Program arguments: llc-12 -O2 -enable-tbaa -relocation-model=pic -mcpu=arm7tdmi -mattr=+soft-float,-vfp2,-vfp2sp,-vfp3,-vfp3d16,-vfp3d16sp,-vfp3sp,-fp16,-vfp4,-vfp4d16,-vfp4d16sp,-vfp4sp,-fp-armv8,-fp-armv8d16,-fp-armv8d16sp,-fp-armv8sp,-fullfp16,-fp64,-d32,-neon,-crypto,-dotprod,-fp16fml,-bf16,-mve,-mve.fp,-fpregs,+strict-align /tmp/ghc5537_0/ghc_6.bc -o /tmp/ghc5537_0/ghc_7.lm_s
1. Running pass 'Function Pass Manager' on module '/tmp/ghc20177_0/ghc_6.bc'.
2. Running pass 'ARM Instruction Selection' on function '@"stg_gc_f1$def"'
`llc-12' failed in phase `LLVM Compiler'. (Exit code: -6)
make[3]: *** [rts/ghc.mk:325: rts/dist/build/HeapStackCheck.o] Error 1
In order to be able to perform a cross-build, we need to use
the stage1 binaries during installation. Both ghc and ghc-pkg
are run during the install target and therefore must be able
to run on the build machine.
Gbp-Pq: Name use-stage1-binaries-for-install.patch
This patch enables a few native 64-bit integer instructions
on x32 which are available on this architecture despite using
32-bit pointers. These instructions are present on x86_64 but
not on x86 and ghc checks the size of (void *) to determine
that. This method fails on x32 since despite using 32-bit
pointers and hence sizeof(void *) == 4, it still uses the
full x86_64 instruction set and software-emulated variants
of the aforementioned 64-bit integer instructions are
therefore not present in the toolchain which will make ghc
fail to build on x32.
See: https://ghc.haskell.org/trac/ghc/ticket/11571
Jani writes: The D16 part was Debian/Ubuntu specific, IIRC we define hardfloat
in that particular variant (16 double registers) or we had a different naming
for some reason.
[changes brought forward from 7.6.3-21+rpi1 by Peter Michael Green <plugwash@raspbian.org> at Sun, 19 Apr 2015 14:00:16 +0000]
* Change compiler defaults for armv6
[changed introduced in 7.10.3-2+rpi1 by Peter Michael Green]
* Add call to dh_autoreconf_clean
[changes brought forward from 9.0.2-4+rpi2 by Peter Michael Green <plugwash@raspbian.org> at Tue, 04 Oct 2022 05:00:41 +0000]
* Add build-conflicts on libllvm14
[changes brought forward from 9.0.2-4+rpi3 by Peter Michael Green <plugwash@raspbian.org> at Wed, 05 Oct 2022 13:33:13 +0000]
* Add build conflicts on libnuma1
projects / ghc.git / log